1. Field of the Invention
The invention concerns a protocol for reading and writing data stored in volatile memory and possibly also in non-volatile memory.
2. Description of the Prior Art
The invention has a particular application to telecommunication network control systems. In a system of this kind, applications manipulate variables that are semi-permanent in the sense that their values are rarely modified. Reading therefore occurs much more frequently than writing. Also, reading must be effected in a very short time. What is read is mainly tables containing variables relating to users.
A set of read and/or write operations on variables requested by an application in one and the same request is called a transaction. If the values of a variable must be modified, a conventional transactional protocol includes the allocation to a given transaction, for a given register, of a write lock which is an exclusive right authorizing the transaction, and only that transaction, to read and to write the value stored in the register, for as long as the write lock exists. Write transactions must therefore wait if the value of the variable that they require to read is currently being modified by another transaction. This wait continues until the end of the transaction that makes the modification. Write operations therefore reduce the performance of read operations.
In a telecommunication network management system this problem is usually aggravated by the fact that the volatile memory is backed up by non-volatile memory. The data is stored in volatile semiconductor memory for fast access and backed up in non-volatile memory having a much longer access time. The volatile memory is associated with a processor. The volatile memory and the processor are both subject to failure, and failure of one leads to failure of the other. In the event of a failure all of the data contained in the volatile memory is lost.
The non-volatile memory usually comprises mirror disks associated with a disk controller responsible for the security of the stored data. It is accessible to any program run on the processor via a service providing access to the non-volatile memory. It is subject to much fewer failures than the processor/volatile memory combination.
Failure of the processor/volatile memory combination does not lead to failure of the non-volatile memory. Also, the non-volatile memory access service is available as soon as the processor is operating. This service has the following properties:
requests to read or write the same data are strictly serialized; PA1 all requests elicit a response from the non-volatile memory access service when the request has been executed; PA1 the service guarantees that in the event of failure of the processor the request is either executed in full or not executed at all. PA1 For any pair of transactions, access to the critical variables of that pair of transactions by either of the two transactions is executed entirely before access to the same critical variables by the other transaction. PA1 In the case of a concurrent plurality of transactions or in the event of failure of the processor, either all of the operations constituting each transaction are executed or none of these operations are executed. PA1 an opening phase; PA1 an access phase during which read or write operations are required and during which rights called read locks and write locks are allocated to the transaction for the register concerned; PA1 a closing phase during which the required reads and writes are executed and the corresponding locks are released. PA1 allocating a read lock prohibiting writing to said transaction for said register; PA1 then reading the content of said register; PA1 allocating a write intention lock to said transaction for said register prohibiting writing in said register by any transaction other than said transaction, but allowing reading; PA1 associating a log register with said register and storing therein said new value of said variable; PA1 determining each register to which a write intention lock has been allocated for said transaction to be closed; PA1 releasing any write lock allocated to said transaction to be closed; PA1 then, for any register holding a write intention lock, for said transaction to be closed, verifying that there remains no read lock allocated to any other transaction for said register; if at least one read lock remain for a time period exceeding a fixed limit, executing a procedure to abort said transaction to be closed; or otherwise converting said write intention lock into a write lock; PA1 then, for any register holding a write lock for said transaction to be closed: PA1 then sending a "transaction deemed completed" message to an application that requested closure of said transaction; PA1 clearing the content of each log storing the value of a variable modified by the aborted transaction; PA1 then releasing write locks and write intention locks allocated to said aborted transaction; PA1 then sending a "transaction aborted" message to said application that requested closure of said transaction. PA1 allocating a read lock prohibiting writing to said transaction for said first register, PA1 then reading the value of said register; PA1 allocating to said transaction, for said first register, a write intention lock prohibiting writing in said first register by any transaction other than said transaction to be closed, but allowing reading; PA1 associating with said first register a first log register and storing therein said new value of said variable; PA1 for any first register to which a write intention lock has been allocated by said transaction to be closed: PA1 then writing the identifier of said transaction into a table of transactions stored in said non-volatile memory; PA1 releasing any read lock allocated to said transaction to be closed; PA1 then, for any first register holding a write intention lock, for said transaction to be closed, verifying that there remains no read lock allocated to any other transaction for said register, and, if at least one read lock remains during a time period exceeding a fixed limit, executing a procedure to abort said transaction to be closed; and otherwise converting said write intention lock into a write lock; PA1 then, for any first register holding a write lock, for said transaction to be closed: PA1 then sending a "transaction deemed completed" message to an application that requested closure of said transaction; PA1 then writing in said table an indicator associated with said identifier of said transaction and indicating that the latter is deemed completed; PA1 then, for any second register holding a write lock, for said transaction to be closed: PA1 and finally clearing said identifier of said transaction in said table; PA1 clearing the content of each first log holding the value of a variable modified by the aborted transaction; PA1 then releasing write intention locks and write locks allocated to said aborted transaction, for said first register; PA1 clearing the identifier of said aborted transaction in said table; PA1 then sending a "transaction aborted" message to said application that requested closure of said transaction; PA1 then clearing the content of each second log storing the value of a variable modified by said aborted transaction; PA1 then releasing write locks allocated to said aborted transaction for said second registers; PA1 for any second register of said non-volatile memory, verifying if any write lock remains in said register, and: PA1 finally, clearing all transaction identifiers in said table.
The data stored in the two memories includes variable values that can be read or written. Each value is stored in a logic register of the volatile memory and in a logic register of the non-volatile memory. It is therefore necessary to maintain the consistency of the value in volatile memory and the value in non-volatile memory, between the various variables and for each variable.
When an application has to read data it is sufficient to read it only in the volatile memory. Thus applications never write the non-volatile memory.
On the other hand, when an application wishes to modify data it is essential to modify it in the volatile memory and in the non-volatile memory so that the content of the volatile memory can be restored correctly after a failure. The problem then arises of sequencing the two operations of writing the new value relative to any operations to read the same variable in the volatile memory, which can be requested at virtually the same time by other applications.
At first sight it would seem essential to prohibit an application from reading the new value in the volatile memory before that value has been written both into the volatile memory and into the non-volatile memory. If a failure were to occur immediately after the writing of a new value into the volatile memory, but before the new data had been written into the non-volatile memory, restoring the content of the volatile memory would write the old value back into the volatile memory. Thus if reading of the volatile memory were permitted immediately after writing of the new value into it, without verifying that the value had also been written into the non-volatile memory, the reader application would obtain a value inconsistent with the content of the volatile memory, following the failure and the restore.
To maintain the mutual consistency of the data written into the two memories, it would therefore seem necessary to make any application requesting to read the value of a variable that is being modified by another application wait. This waiting time is long, however, since a non-volatile memory is usually made up of disks and has a much longer access time than volatile memory which is usually constructed from semiconductor flip-flops. This waiting time is not acceptable in telecommunication applications such as call processing, where the reaction time is a key quality criterion.
The transactional protocols used until now in telecommunication network control systems have neglected this waiting time problem. The problem has therefore had to be dealt with by each application, adding to the cost of developing and debugging each application.
The problem of maintaining the consistency of a set of modification and/or read operations performed on common data is encountered in the field of databases. It has been resolved by means of a transaction service.
The consistency requirements as defined above can be met by offering a so-called "atomic" transaction service. The expression "critical variables" refers to all the variables of a pair of transactions that can be accessed simultaneously by the two transactions. The execution of a plurality of transactions is said to be atomic if:
Each transaction comprises three phases:
The locks prohibit other operations that would compromise the consistency of the data. A read lock allocated to a given transaction for a given register is a non-exclusive right allocated to that transaction authorizing it to read the value stored in that register. Its essential function is to prohibit the allocation of a write lock to another transaction for the same register. A write lock allocated to a given transaction for a given register is an exclusive right allocated to that transaction authorizing it, and it only, to write a value into that register. A read lock can be allocated for a register only on condition that no write lock has already been allocated for that register. A write lock can be allocated for a register only if no write lock and no read lock have already been allocated for that register.
The requirement for transactions to be atomic, in this sense, can seriously degrade read performance. In the prior art transactional protocol previously described the exclusion of reading is effective immediately from access to data to be modified by a transaction and applies until closure of that transaction. The exclusion time can be long and is fixed not by the database management system but by the user. For some types of data, such as the data used for call processing in a telecommunication network, this inability to carry out read operations would be unacceptable.
The aim of the invention is to propose a transactional protocol allowing read access to a memory without waiting due to writing whilst preserving the atomic property of the transactions and that can be implemented in a data access service common to all sorts of applications.
Another aim, in connection with data stored identically in volatile memory and in non-volatile memory, is for the data to remain available and consistent after any short-term failure of the processor and the volatile memory. To be more precise, the aim of the invention is to define which data is to be stored in non-volatile memory and which data is to be stored in volatile memory and to define the protocol to be executed to read or write this data or to restore the content of the volatile memory after failure thereof or of the associated processor.